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5-H Abstract. Usual techniques to solve WCSP are based on cost transfer opera- 

tions coupled with a branch and bound algorithm. In this paper, we focus on an 
approach integrating extraction and relaxation of Minimal Unsatisfiable Cores in 
order to solve this problem. We decline our approach in two ways: an incomplete, 
greedy, algorithm and a complete one. 
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1 Introduction 



The Constraint Satisfaction Problem (CSP) consists in determining if a Constraint Net- 
work (CN), also called a CSP instance, is satisfiable or not. It is a decision problem, the 
goal of which is to find a solution, i.e., a complete instantiation of the variables of the 
CN that satisfies each constraint. Sometimes, preferences among solutions need to be 
As expressed. This is possible through the introduction of soft constraints. The framework 

■^ called WCSP (Weighted CSP) allows us to handle such constraints: each soft constraint 

■^ is defined by a cost function that associates a violation degree, called cost, with every 

'^ possible instantiation of a subset of variables. The WCSP goal is to find a complete 

■^ instantiation with a minimal combined cost of the soft constraints. 

^D Most of the current methods to solve Weighted CNs (WCNs) are based on branch 

^^ and bound tree search together with the use of soft local consistencies for estimating 

. . minimal costs of sub-problems during search. These local consistencies, e.g., AC* [12, 

13], FDAC [3], EDAC [6], VAC [4], and OSAC [5], have been developed on the concept 
of equivalence-preserving transformations (cost transfer operations). Because they must 
;J] combine costs, algorithms establishing soft local consistencies are often more complex 

Cu than their CSP counterparts. In this paper, we propose an original approach for WCSP 

that consists in solving a WCN by iterative ly generating and solving classical CNs. 
One advantage is to benefit from efficient CSP solvers developed in the community for 
more than two decades. Notice that reformulating WCNs into CNs has already been 
used quite successfully to enforce VAC [4], where (classical) arc consistency is estab- 
lished on a CN generated from a WCN in order to identify some relevant cost transfer 
operations. 

In our approach, to solve a WCN, soft constraints are converted into hard con- 
straints by retaining only the tuples that have a specified cost. Actually, the principle 
is to enumerate a sequence of CNs according to an increasing cost order related to the 



WCN. When a CN is proved to be unsatisfiable, a Minimal Unsatisfiable Core (MUC) 
is extracted in order to identify the soft constraints whose reformulations into hard con- 
straints need to be relaxed, so as to finally obtain a solution. This approach is declined 
in two versions: a complete algorithm and a greedy one (that is incomplete). Note that 
related approaches have been successfully exploited for MaxSAT [1, 9, 16]. 

This paper is organized as follows. After some usual definitions, we present the 
principle of our approach and the required data structures. Next, we completely describe 
a complete version of our approach, as well as a greedy one. Finally, after presenting 
some practical results, we conclude. 

2 Technical Background 

2.1 Generalities 

A constraint network (CN) P involves a finite set of n variables denoted by vars{P) 
and a finite set of e constraints denoted by cons{P). Each variable x has an associated 
domain, denoted by dom[x), which contains the finite set of values that can be assigned 
to x; the initial domain of x is denoted by dom™^^ (x) . Each (hard) constraint c involves 
an ordered set of variables, denoted scp{c) and called scope of c, and is defined by a 
relation containing the set of tuples allowed for the variables of scp{c). The arity of a 
constraint c is |scp(c)|. An instantiation / of a set X ~ {xi, . . . , Xp] of variables is 
a set {(xi, ai), . . . , (xp, a^)} such that Vi e l..p, a^ e (ioTO™**(xi). / is valid on P 
iff V(x, o) G J, a € dom{x). A solution is a complete instantiation of vars{P) (i.e., 
the assignment of a value to each variable) such that all the constraints are satisfied. 
P is satisfiable iff it admits at least one solution. For more information on constraint 
networks, see [8, 14, 18]. 

An unsatisfiable core of P is an unsatisfiable subset of constraints of P. A core 
C is a MUC (Minimal Unsatisfiable Core) iff each strict subset of constraints of C 
is satisfiable. Several methods to extract MUCs of constraint networks are presented 
in [7, 11, 10]. Among the different versions presented in [10], we have chosen for our 
implementation the dichotomic version, called dcMUC. 

A weighted constraint network (WCN) W involves a finite set of n variables de- 
noted by vars{W) and a finite set of e soft constraints denoted by cons{W), and has 
an associated value fc > which is either a natural integer or +oo. Each soft constraint 
w G cons{W) has a scope scp{w) and is defined as a cost function from l{scp(w)) to 
{0, . . . , k}, where l{scp(w)) is the Cartesian product of the domains of the variables 
involved in w; for each instantiation / £ l{scp{'w)), the cost of / in w is denoted by 
w{I). 

When an instantiation is given the cost k it is said forbidden. Otherwise, it is per- 
mitted with the corresponding cost (0, being completely satisfactory). 

Costs are combined with the bounded addition defined as: 

Va, b G {0, . . . , fc}, aO) b — min{k, a + b) 

The objective of Weighted Constraint Satisfaction Problem (WCSP) is, for a given 
WCN, to find a complete instantiation with a minimal cost. For more information on 
weighted constraint networks, see [2, 17]. 



Different variations of soft arc consistency for WCSP have been proposed during 
the last decade: AC* [12, 13], full directional arc consistency (FDAC) [3], existential arc 
consistency (ED AC) [6], virtual arc consistency (VAC) [4] and optimal soft arc consis- 
tency (OS AC) [5]. All the algorithms proposed to enforce these different levels of con- 
sistency use cost transfer operations (based on the concept of equivalence-preserving 
transformations) such as unary projection, projection and extension. 



2.2 Layers and Fronts 

In this paper, we focus on extensional soft constraints. These are soft table constraints 
where some tuples are explicitly listed with their costs in a table, and a default cost 
indicates the cost of all implicit tuples (i.e., those not present in the table) ; e.g., see 
[15]. Below, we introduce both the notions of layer and front. 

All tuples of a soft table constraint having the same cost can be grouped to form a 
subset called layer. The cost of any tuple from layer L is given by cost{L). A particular 
layer corresponds to the default cost: this layer contains no tuple, but implicitly repre- 
sents all tuples that do not explicitly appear elsewhere (in another layer). The number 
of layers for a constraint w is given by nbLayers{w). Within a constraint, we consider 
that layers are increasingly ordered according to their costs. Finally, for the sake of sim- 
plicity, we shall use indices, from to nbLayers{w) — 1, to identify the different layers 
of a constraint, and when the context is unambiguous, we shall not distinguish between 
indices and the layers they represent. 

A front / is a function that maps each constraint of a WCN to one of its layers. A 
front represents a kind of border between the layers that will be considered (allowed) at 
a given moment, and the layers that will be discarded (forbidden). We shall use an array 
notation for the fronts. So, f[w] will represent the layer associated with the constraint 
w in the front /. The cost of a front /, cost{f), is obtained by summing up all costs of 
the constraint layers corresponding to the front / : 

cost(f) = ^ cost{f[w]) 

w(^cons{W) 

A front /' is the direct successor of a front / iff there exists a constraint Wi such 
that f[wi] = f[wi] + 1 and ^j^i, .f'[wj] = f[wj]. We note / -^ /' iff /' is a direct 
successor of / and / ^* /' iff there exists a sequence of relations / -^ fi, fi -^ 
/2, • • • /n — >■ /' (transitive closure). 

Because the layers of any constraint are increasingly ordered following their costs, 
we deduce that: 

/ ^, /' => cost{f) < costif) 

We can observe that the set of all possible fronts and the direct successor relation 
form a lattice structure, where the lowest front (also noted _L) associates with each 
constraint its first layer (of lowest cost) and the highest front (also noted T) associates 
with each constraint its last layer (of highest cost). 



3 General Principle 



Figure 1 illustrates the main idea of our approach for solving weighted constraint net- 
works. First, from a WCN W, an initial constraint network P is built as follows: for 
each constraint of W, the tuples occurring in the layer of minimal cost are considered as 
allowed in P, while other tuples are considered as forbidden (function toCN). This pro- 
cess is similar to that proposed in [4]. Next, the CN P is solved using a constraint solver 
(through a call to the function solveCN). If P is satisfiable, then a solution is returned. 
Otherwise a MUC is extracted from P (through a call to the function extractMUC) 
and then exploited either in a greedy or complete version. 

In the greedy version, some constraints of the MUC will be successively relaxed 
until satisfiability of the MUC is restored (through a call to the function relax). More 
precisely, a subset of layers of some constraints belonging to the MUC will be switched 
from the "forbidden" status to the "allowed" one. When constraints corresponding to 
the MUC are relaxed so as to become satisfiable, the process loops until the global 
satisfiability of P is reached. In this case, a solution is returned. 

In the complete version, once a MUC is identified, we insert in a priority queue 
fronts that represent all possible ways of relaxing the MUC. Fronts are extracted from 
the priority queue, translated to a CN, and successively solved until the occurrence of a 
satisfiable constraint network. In this case, an optimum solution is returned. 
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Fig. 1. Principle of the iterative relaxation of MUCs. 



Interestingly, the principle described above can be generalized to take into account 
any kind of constraint: hard constraints from the CSP framework, "violable " constraints 
from the Weighted Max-CSP framework and soft constraints from the WCSP frame- 
work. When the function toCN is called, we just need to indicate the translation pro- 
cess for each kind of constraints. For a hard constraint, no transformation is required 
(we have only one layer with a cost equal to 0). For a "violable" constraint, two layers 
are managed. The first layer, with a cost equal to 0, corresponds to the satisfaction of the 
"violable" constraint. The second one, with a cost equal to the weight of the "violable" 
constraint, corresponds to the violation of the constraint. In other words, our approach 
allows us to deal easily and naturally with these different frameworks. Due to lack of 
space, this is not further described in this paper. 

4 Data structures and Functions 

Fronts are exploited by the function toCN which builds a CN from a WCN. Two ver- 
sions are considered. The first one, noted toCN={W, /), builds a CN by selecting as 
allowed tuples for a soft constraint w those belonging to the layer /[w] ; this layer is 
said allowed. The second one, noted toCN<:(W, f), builds a CN by selecting as al- 
lowed tuples for a soft constraint w the tuples of the layers whose index is less than or 
equal to f[w] ; these layers are said allowed. In other words, for each hard constraint 
c built from a soft constraint w of W, the tuples allowed in c are those having a cost 
equal (resp., less than or equal) to the cost of the layer f[w]. 

In practice, two representations of a hard constraint can be envisionned. On the one 
hand, when the layer corresponding to the default cost is not allowed, toCN generates 
a hard positive constraint. The tuples of the hard constraint are allowed and correspond 
to the tuples of the allowed layers of the soft constraint. On the other hand, when the 
layer corresponding to the default cost is allowed, toCN generates a hard negative 
constraint. The tuples of the hard constraint are forbidden and correspond to the tuples 
of the forbidden layers of the soft constraint in order to avoid to enumerate the implicit 
tuples having a cost equal to the default cost. 

Figure 2 presents two constraints w^ and wi with their layers. Constraint wq has 
a set of layers numbered from 0: layer of minimal cost costo contains the tuples 
Ti, T5, and Ty, and the next layer (layer 1) of cost costi contains the tuples T2 and 
T3. In this example, f[wo] is equal to 1 and f[wi] is equal to 0. The CN returned by 
toC N={W, f) contains a constraint cq (associated with wa) with allowed tuples T2 and 
Ta and a constraint ci (associated with wi) with allowed tuples ti and T4. The CN 
returned by toC N<:{W, /) contains a constraint cq (associated with wq) with allowed 
tuples T2, T3, Ti, T5, and T7 and a constraint ci (associated with wi) with allowed tuples 
Ti and T4. Allowed layers of toCN<:{W, /) are identified by a grey background in 
Figure 2. 

We conclude this section by a short description of the other functions we need. The 
function solveCN [P) solves a CN given in parameter and returns either a solution or 
_L if the CN is unsatisfiable. The function extractMUC (P) returns a MUC from an 
unsatisfiable CN P given in parameter. The function cons{W, M) returns the set of soft 
constraints of the WCN W which correspond to those of the MUC M (by construction 



any hard constraint is associated with a soft constraint). The function restrict{W, M) 
returns a WCN containing only the constraints of the WCN W corresponding to the 
constraints present in the MUC M. 
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Fig. 2. Description of data structures. 



5 Algorithms 

5.1 Introductory Complete Version 

To facihtate the understanding of our approach, we present a first complete algorithm 
which does not exploit MUCs and thus is not efficient. Function completeSearchNoMUC 
starts with a first front which retains only layer of each constraint (lines 1-3). Next, 
while there exists a front to explore, we extract from a priority queue the front with the 
minimal cost. The cost of a front is easily computed by summing the costs associated 
with the layers selected in each soft constraint. Then, we can build with the function 
toCN ^ a CN that we try to solve with solveCN. If a solution is found, it is optimal 
and the algorithm stops. Indeed, the algorithm enumerates fronts in increasing cost or- 
der (see Proposition 1) and guarantees that each previous front was unsatisfiable. If the 
tested CN was unsatisfiable, we enumerate the direct successors of the current front 
(lines 11-16) and insert them in the priority queue. Obviously, we have to check that 
we are not exceeding the maximal layer for a given constraint. Besides, fronts having a 
cost equal to k must be ignored. 

The priority queue Q used in this algorithm is a variant of the usual priority queues 
because it must ensure that fronts are extracted in increasing cost order but also that a 



Function completeSearchNoMUC(W^: WCN) 



1 foreach w G cons{W) do 

2 I f[w] ^ 

4 while Q / do 

5 / <— pick and delete least cost front in Q 

6 P^toCN={W,f) 

7 sol •(- solveCN{P) 

8 If sol / _L then 

9 I return sol 
10 else 

foreach w € cons{W) do 

If /[kj] 7^ nbLayers{w) — 1 then 

/'M^/'H + i 

If cost(f') / fc then 

L ^ u /' 



given element is not inserted twice in the queue. For example, if we consider a network 
composed of two constraints each having at least two layers, the first front will be the 
array < 0, >. During the first iteration, we shall insert in Q the neighbors < 1, > 
and < 0, 1 >. When these fronts are extracted from the queue, they both generate 
the same neighbor < 1, 1 > that must be inserted only once in Q to avoid redundant 
computations. This particular queue is obtained by slightly modifying a classical im- 
plementation of a priority queue with a binomial heap. 

One can easily check that Algorithm completeSearchNoMUC enumerates all pos- 
sible fronts when solveCN never finds a solution. Indeed, if we ignore costs, this algo- 
rithm performs a breadth-first search enumerating fronts. Proposition 1 also guarantees 
that this algorithm does not loop endlessly and that fronts are enumerated in increasing 
cost order. 

Proposition 1. The following properties are guaranteed by completeSearchNoMUC: 

A) fronts are enumerated in increasing cost order; 

B) once a front f is extracted from the priority queue, it can never be inserted again. 

Proof. Let /i be a first front extracted from the queue and /2 a front extracted from the 
queue after the extraction of /i . 

A) Two cases are possible. Either (A.l) /2 was already present in the queue when 
/i has been extracted or (A.2) /2 has been inserted in the queue after the extraction of 
/i. In case (A.l), the priority queue ensures that cost{fi) < cost{f2). In case (A.2), 
/2 comes from a front / such that / ^-^ /2 and either / — fi or f was present in the 
queue when /i has been extracted. In both cases, cost{fi) < cost{f). As / ^* /2 => 
cost{f) < cost{f2), we conclude that cost{fi) < cost(f2). Therefore, we obtain that 
in any case cost{fi) < cost{f2). 



B) Let us assume that /i = /2. As the queue ensures that it never contains two iden- 
tical fronts at a given time, we conclude that we are necessary in case (A. 2). However, 
we proved that in this case, cost{fi) < cost{f2), which contradicts /i = [2- □ 

It should be emphasized that in our approach, unary constraints are considered as 
normal constraints. Moreover, because only one layer of a constraint is considered at 
a given time, the CN generated are typically much smaller than the original WCN. 
One can expect that checking the satisfiability will be quite simple (hence fast) in most 
cases. One last observation here is that this algorithm exploits a form of abstraction 
considering that, from a global point of view, there is no reason to distinguish tuples 
having the same cost. 

To conclude this section, the drawback of this first version is the enumeration of 
all possible combinations of layers. In the worst-case, it enumerates a number of fronts 
equal to the product of the number of layers of each constraint, which corresponds to 
n«)Gcons(iv) nbLayers{w). Depending on the number of variables and constraints, this 
complexity may be much greater compared to a classical branch and bound approach 
(i.e..,whenYl^^^^^^f^yy^nbLayers{w) :g> Hi |(iom(xi)|). This is explained by the fact 
that, in our approach, the same instantiation can be explored several times in different 
tests of satisfiability. Nevertheless, even in this case, this approach can be effective if 
the optimum is low. 

5.2 Exploiting MUCs 

The complexity of the previous algorithm can be reduced considerably in practice by 
noticing that it is useless to move from a layer to the next one for a constraint which 
does not participate in the unsatisfiability of the CN. The idea is therefore to identify a 
MUC and to move to the next layer only for the constraints belonging to this MUC. 

In the worst-case, the MUC extracted contains all the constraints of the problem and 
therefore the complexity in the worst-case remains unchanged. However in practice, on 
concrete instances, MUCs are often small. Hence, the generated neighbourhood is much 
smaller and the practical complexity is significantly reduced. 

Complete Approach Function completes earch (inspired by [1, 9, 16]) presents the al- 
gorithm modified in order to take profit of MUCs in a complete approach. The first steps 
of the algorithm are identical to those of completeSearchNoMUC. When the current CN 
is unsatisfiable, a MUC is identified, and we shall progressively allow the higher layers 
in the constraints of the MUC. More precisely, the algorithm enumerates all the pos- 
sible ways to relax this MUC. For each constraint of the MUC (obtained by a call to 
cons{W, M)), the algorithm generates a successor /' from the current front which dif- 
fers only by the incrementation of the allowed layer for this constraint. This new front 
is inserted in Q at a position depending on the value of cost{f'). 

Proposition 2. Algorithm completeSearch is complete. 

Proof. To simplify the proof, we shall use the term "front" to refer implicitly to the CN 
associated with a front / by toCN^{W, /). Let /„ be the front which is identified as 



Function completeSearch(T4^: WCN) 



1 foreach w G cons{W) do 

2 I f[w] ^ 

4 while Q / do 

5 / <— pick and delete least cost front in Q 

6 P^toCN={W,f) 

7 sol •(- solveCN{P) 

8 If sol / _L then 

9 I return sol 

10 else 

11 M ^ extractMUC{P) 

12 foreach to e cons(VK, M) do 

13 if /[™] 7^ nbLayers{'w) — 1 then 

14 /' ^ / 

15 /'M^/'H + i 

16 If cost{f') 7^ fc then 

17 ^Q^QU{/'} 



unsatisfiable and M the MUC extracted from this front. The only difference between 
completeSearch and completeSearchNoMUC is that when a MUC is identified, we re- 
strict the search by relaxing this MUC prior to any other operation. 

If the WCN has no solution, restricting the search in this way obviously does not 
cause the loss of any solution. We can therefore only consider the case where the CN 
admits at least one solution 5*. Let fs be the front corresponding to a solution S. The 
algorithm completeSearchNoMUC ensures that there always exists a front / in the pri- 
ority queue such that / ^* fs- This is especially true for the first front inserted in the 
queue _L and when this property is satisfied for a front extracted from the queue, it is 
satisfied for at least one of its direct successors (by definition of ^*). Therefore, by 
recurrence, this property is always ensured. 

If /« 7^* fs, the proposed restriction does not result in the loss of solution S. 
Therefore, we can further assume that /„ ^* fs- Hence, \/w E cons{W), fs[w] > 
fu[w]. Moreover, there necessarily exists a constraint Wi E cons{W,M) such that 
fs[u!i] > fu[wi], otherwise fs will still be unsatisfiable. Let /' be the front defined by 
f'[wi] = fu[wi] + 1 and Vw € cons{W) such that w ^ Wi, /'[w] = /m[w]. /' is a front 
which is generated by the algorithm and by construction f ^* fs- □ 

Figure 3 presents an example where one cannot simply relax a MUC in only one 
way, even if it was locally the optimal relaxation, without losing the optimal solution. 
In this example, a WCN is composed of three constraints w^, w^y and Wy. The first 
front selects the layers having a cost equal to 0, and therefore only retains {(x, a)}, 
{(a:, a), (y, 6)} and {(y,a)} as allowed tuples. Of course, in this case, the constraints 
Wxy and Wy constitute a MUC. There are two ways to relax this first MUC. The first 
relaxation switches to the next layer of Wxy (it is locally the best choice since it has a 



cost of 5) whereas the second one switches to the next layer of Wy. Considering the first 
case, the new front obtained retains {{x, a)}, {{x, c), {y, a)} and {{y, a)} as allowed 
tuples. This time, the MUC contains the constraints w^ and w^y. We can either relax 
Wxy to obtain a solution with a cost of 100, or relax w^ to obtain another MUC that can 
be relaxed in two different ways to obtain either a solution having a cost of 105, or a 
solution having a cost of 110. 

The second relaxation of the first MUC consists in switching to the next layer of Wy . 
In this case, we directly obtain a solution having a cost of 10, which is the optimum. 
This clearly shows that all relaxations of a MUC are required. 
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Fig. 3. Example where it is required to enumerate all relaxations of a MUC to reach the optimum. 



Greedy Approach In this part, we present an incomplete version of our approach based 
on the identification and relaxation of MUCs in order to solve WCNs. 

From a WCN W, Function incompleteSearch returns a solution for a CN derived 
from W. First the structure front is initialised to which corresponds to the first layer 
of each constraint of the WCN. 

From a WCN W and a front /, we extract a CN and this network is then solved. If 
a solution is found, then it is returned by the function incompleteSearch (line 7). If the 
network has been proved unsatisfiable, it is necessary to relax some constraints of the 
WCN. To achieve this, the algorithm extracts a WCN W' from a computed MUC (lines 
9 and 10). The front / is then updated by Function relax (line 11). This procedure will 
relax one (or several constraints) of W' in order to break the MUC associated with W' . 
This process loops until a solution is found for the constraint network associated with 
W. 

Function relax{W, /) updates the front / in order to allow new layers. The idea 
is to increment f[w] for at least one constraint w, in such a way as to make the MUC 
satisfiable. In other words, for at least one of the constraints, we accept an increase of 
cost for this constraint. In the greedy approach used here, we keep doing this until the 
MUC is broken. 

Algorithm relax uses a local priority queue Qioc which is initialized with the front 
/. While Qioc is not empty (line 2), we extract from the queue the front / having 
the lowest cost cost(f). Function toCN< builds a constraint network from both the 
WCN and the front / previously selected (line 4). If this constraint network is satis- 
fiable, / initially given in parameter is updated and returned by the algorithm relax. 
On the contrary, if the constraint network is unsatisfiable, it means that the relaxation is 



Function incompleteSearch(W^: WCN) 



1 foreach w G cons{W) do 

2 I /M^o 



3 repeat 


4 


P^ toCAf<(W^,/) 


5 


so? ^ solveCN{P) 


6 


if so/ 7^ ± then 


7 


1 return sol 


8 


else 


9 




M ^ extractMUC{P) 


10 




W ^ restrict {W, M) 


11 




/<- relax{W',f) 


12 until soZ 7^ _L 



not sufficient and then the algorithm updates the queue of fronts by generating all the 
neighbors of /. For each constraint belonging to the WCN (obtained from the MUC), 
we generate a new front, different from the initial one, by incrementing the layer of one 
single constraint. 

Note that in the different calls to the function relax, it is sufficient to work only on a 
subset of the constraints. Indeed, the constraints that can be relaxed are those belonging 
to the WCN W associated with the MUC (restrict{W, M)). In practice, we only work 
with the subset of the front which corresponds to contraints of the MUC, which saves 
space (for simplicity, this is not detailed in the algorithm). 

In the incomplete version, we transform a WCN into a CN using function toCN < 
instead of toCN= which is used in the complete version. Indeed, in the complete ver- 
sion, all possible relaxations of a MUC are considered and the fronts are enumerated 
in increasing cost order Hence, when we test the satisfiability of a CN associated with 
a front /, we know that all the CN associated with fronts /' such that /' — ?•* / have 
already been proved unsatisfiable. In the complete version, toCN= extracts a CN com- 
posed of the current layers of a front. In the incomplete version, all possible relaxations 
of a MUC are not tried. Therefore, we cannot ensure that, when we test the satisfiabil- 
ity of a CN associated with a front /, all the CNs associated with fronts /' such that 
/' -^^ f have been tried and already proved unsatisfiable. Function toCN<: therefore 
extracts a CN from both the current and inferior layers of a front. 

This approach doesn't guarantee the identification of an optimum solution. The rea- 
son is that all the relaxations of MUCs are not considered, contrary to the complete 
version (see Example 3). Indeed, we only identify the first relaxation which restores 
satisfiablity of a MUC. 



6 Experimental Results 

In order to show the practical interest of our approach, we have performed experiments 
using a computer with processors Intel(R) Core(TM) i7-2820QM CPU 2.30GHz. Our 



Function relax(VF: WCN, f: front): front 



1 Qloc ^ {/} 

2 while Qloc / do 

3 f <~ pick and delete least cost front in Qioc 

4 P^toCN<(W,f) 

s it solveCN (P) ^ ± then 

6 I return / 

7 else 

8 M <- extractMUC{P) 

9 foreach w G cons{W, M) do 

10 if /[^f] 7^ nbLayers{w) — 1 then 

11 /' ^ / 

12 /'H^/'H + i 

13 If cost{f') / fc then 

14 |_ Qloc ^ Qioc U {/'} 



greedy approach, noted GMR, has been compared with two complete approaches with 
cost transfer algorithms enforcing EDAC, proposed by both our solver AbsCon and the 
solver ToulBar2. A time-out of 600 seconds was set per instance. The total CPU time 
necessary to solve each instance is given as well as the upper bound found (UB). If the 
execution of the algorithm is not yet finished before the time-out (CPU time greater 
than 600 seconds), the bound found at the end of the 600 seconds is given. Table 1 
provides the results obtained for the serie spot5 (except trivial instances) composed of 
constraints of arity less than or equal to 3. Table 2 provides the results obtained for the 
serie celar. 

On instances of spoth, we observe that our approach provides better bounds than 
those obtained by the two complete approaches, except for the instances spoi5-404, 
spot5-503 and spot5-1502. Beyond the fact that our approach is not complete, this can 
be explained by the fact that these instances are relatively easy (involving less than 
1,400 constraints) and cost transfer algorithms reach a better bound before the time- 
out. However, it is interesting to note that the bound found by our approach is not so 
different from these obtained by complete approaches, and this in a very short time. 
About other instances, considered as more difficult (in particular, more than 13, 000 
constraints for the instances spot5-1403, spot5-1407 and spoiS- 1506), we observe that 
our greedy approach provides a better bound than those of complete approaches in a 
time shorter than the time-out. 

One can note that GMR is not as competitive as ToulBar2 on some instances of 
celar, seen and graph. This is partly due to the fact that ToulBar2 uses a constraint 
decomposition technique. Indeed, comparing GMR with a classical cost transfer algo- 
rithm (such as in our AbsCon solver), the approach described in this paper outperforms 
the EDAC version of AbsCon. However, on the graph-05 instance, even if GMR is not 
so fast than ToulBar2, our approach is able to find the optimum upper bound. 



AbsCon ToulBar2 

Instances GMR EDAC EDAC 

spot5-42 CPU 9.18 > 600 > 600 

UB 161,050 161,050 161,050 



spoi5-404 


CPU 


4.99 


> 600 


217 




UB 


118 


114 


114 


spoi5-408 


CPU 


9.85 


> 600 


>600 




UB 


6,235 


8,238 


6,240 





spoi5-412 


CPU 


18.8 


> 600 


>600 




UB 


33,403 


43, 390 


37, 399 






37.7 
40, 500 


> 600 
56, 492 




spot5-414 


CPU 


> 600 




UB 


52,492 




CPU 


6.33 






spof5-503 


>600 
13,119 


>600 




UB 


12,125 


12,117 












spoi5-505 


CPU 


12 


> 600 


>600 




UB 


22,266 


28, 258 


25,268 








>600 
37, 429 




spoi5-507 


CPU 
UB 


22.3 
30,417 


>600 
37, 420 




spoi5-509 


CPU 
UB 


32.2 
37,469 


> 600 

48, 475 


>600 

46, 477 


spoi5-1401 


CPU 


76.5 


> 600 


> 600 




UB 


483, 109 


513,097 


516,095 


spot5-1403 


CPU 
UB 


142.5 
481,266 


> 600 
517,260 


>600 

507, 265 












spoi5-1407 


CPU 
UB 


552.6 
492,614 


> 600 
517,623 


>600 
507, 633 


spot5-1502 


CPU 


3.91 


0.98 


0.02 




UB 


28, 044 


28,042 


28, 042 


spot5-1504 


CPU 
UB 


67.6 
175,311 


> 600 
204,314 


>600 

198,318 












spoi5-1506 


CPU 
UB 


338 
378,551 


> 600 
426,551 


>600 
399, 568 



Table 1. CPU time in seconds and bound found before the time-out for instances spotS. 



The preliminary experiments we have conducted on the complete approach show 
that our current implementation is not yet competitive. It clearly appears that MUCs 
must be identified in an incremental way so that the computational effort for a given 



Instances 



AbsCon 
GMR EDAC 



ToulBar2 
EDAC 





CPU 
UB 


16.6 
221 






graph-Q^ 


> 600 


0.62 




4,645 


221 




scen-06 


CPU 
UB 


88.5 
3,616 


> 600 
12,013 


485.4 
3,389 




scen-06-16 


CPU 
UB 


60.6 
4,149 


> 600 


237.7 




11,286 


3,277 






59.2 


> 600 




scen-06-18 


CPU 


102.4 




UB 


3,640 


8,723 


3,263 




scen-06-20 


CPU 


68.5 


> 600 


67.9 




UB 


3,402 


8,594 


3,163 




scen-06-30 


CPU 
UB 


32.6 
2,208 


177.7 
2,080 


1.10 
2,080 




scen-07 


CPU 
UB 


209.9 
426,423 


> 600 
31,230A: 


>600 
505, 731 




CPU 








scen-07_10000_30r 


28.7 


> 600 


>600 




UB 


270K 


i7,oooii: 


1,5007^ 


celar&-sub2 


CPU 


23.3 


> 600 
2,746 


4.74 




UB 


2,927 


2,746 




celar6-sub3 


CPU 
UB 


26.6 
3,271 


> 600 
3,279 


15.7 
3,079 




celar6-sub4 


CPU 


41.5 


> 600 


28.7 




UB 


3,704 


5,178 


3,230 


celar7-sub2 


CPU 
UB 


60.8 
283,955 


>600 
252,436 


17.8 
173,252 


celar7-sub3 


CPU 


48.7 


> 600 
1,342K 


93.4 




UB 


414,161 


203,460 


celar7-sub4 


CPU 


57 


> 600 


221 




UB 


272, 945 


302,541 


242, 443 



Table 2. CPU time in seconds and bound found before the time-out for instances celar. 

front benefits to the others. We are currently exploring the use of dynamic CSP algo- 
rithms to incrementally test the satisfiability of CNs and identify MUCs. 

7 Conclusion 



In this paper, we have proposed an original approach for solving weighted constraint 
networks through successive resolutions of hard constraint networks. More precisely, 



CNs are obtained from WCNs by selecting tuples with a given cost. These CNs are 
enumerated in increasing cost order until a solution is found. To improve the complex- 
ity in practice of our approach, we identify a minimal unsatisfiable core for each un- 
satisfiable constraint network, in order to focus the cost increase on the sole constraints 
of the MUC. The approach is declined in both a complete and an incomplete, greedy 
algorithm. We have shown that our method based on MUCs extraction can be used in 
practice: the greedy algorithm obtains results which are comparable with other state 
of the art approaches. However, the complete algorithm is not yet competitive but we 
have identified several reasons. We are working on a new version using dynamic CSP 
algorithms in order to perform incremental computations. To conclude, we would like 
to emphasize that the proposed method allows a simple and natural integration of the 
CSP, (weighted) Max-CSP and WCSP frameworks. This can be done by generalizing 
in a straightforward way the construction of CNs generated during the resolution. 
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